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In  addition  to  the  lineal  symbol  capability,  the  GLSS  is  capable  of  creating 
a significant  number  of  point  symbols. 

The  software  is  written  in  ASCII  COBOL  and  Fortran  ^ languages  and  requires 
approximately  40K  words  of  memory  for  loading  and  execution  of  all  functions. 

Th®  software  configuration  is  highly  segmented  into  areas  of  job  set-up,  file 
input,  job  monitoring,  symbol  application  control,  symbol  specification 
correlation,  symbol  application  processes,  line  smoothing  and  data  culling, 
job  reporting,  and  file  output. 
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PREFACE 


This  is  Volume  I of  a two  volume  final  technical  report  prepared  by 
PRC  Information  Sciences  Company,  7600  Old  Springhouse  Road,  McLean 
Virginia.  The  report  covers  work  performed  under  Contract  F30602-75-C- 
0319  for  Rome  Air  Development  Center,  Griffis  a Air  Force  Base,  New  York. 
The  report  describes  work  performed  from  June  1975  through  April  1976. 

Mr.  John  R.  Baumann  (1RRC)  was  the  RADC  Project  Engineer,  Mr.  Frank 
Mirkay  was  the  DMAAC  technical  coordinator,  and  Mr.  M.  Lynn  Taylor 
was  the  PRC  Project  Manager. 


ABSTRACT 


PRC/EC,  under  a RADC  contract,  converted  and  expanded  the 
Graphic  Line  Symbolization  System  (GLSS)  to  operate  in  the  production  en- 
vironment at  the  Defense  Mapping  Agency  Aerospace  Center  (DMAAC). 

The  system  was  converted  from  the  HE -635  to  the  UN IV AC  1108.  Major 
enhancements  to  the  original  software  system  included  additional  point 
symbol  capabilities  and  additional  output  file  formats  for  interfacing  with 
DMAAC  plotter  systems.  Major  characteristics  of  GLSS  includes: 

o Hardware  - UNIVAC  1108 

o Software  - written  in  ASCII  COBOL  and  FORTRAN  V compiler 
languages  and  operates  under  EXEC  8. 

o Modularity  - the  software  configuration  is  highly  segmented 
into  areas  of  job  setup,  file  input,  job  monitoring,  symbol 
application  control,  symbol  specification  correlation,  symbol 
application  processes,  line  smoothing,  job  reporting,  and 
file  output. 

o Resources  - requires  approximately  40K  words  of  memory  for 
loading  and  execution  of  all  software;  program  overlaying 
or  selective  loading  of  required  software  can  significantly 
reduce  core  storage. 

GLSS  provides  a wide  range  of  data  processing  capabilities  related 
to  cartographic  symbology.  Various  capabilities,  options  and  processing 
techniques  of  GLSS  includes  the  following: 


Da  shine 


Variable  sizes  of  dashes  and  spaces 

Feature  must  start  and  end  with  dash  at  least  1/2  length  of 
dash  size 

Dash  must  carry  through  points  flagged  as  special  points 


Casing 


Variable  size  cases 

Line  quality  of  case  should  equal  or  exceed  quality  of  original 
line  center 


iv 
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Ticking 
o Full  tick 

o Alternating  half  tick 

o Half  tick  (left  or  right  code) 

o Double  tick 

o Feature  will  not  end  with  a tick 

o Ticks  will  not  be  applied  at  special  points 

Line  Cleaning 

o Cleaning  angles  (angle  bisecting) 

o Minimum  resolution  maintenance 

o Line  "back-up"  edit 

o Combinations  of  the  above  options 
o Data  culling  based  on  line  inclination  factors 

Symbol  Specifications 

o Specification  file  building  and  update 
o Selection  of  specification  file  (multiple  product  files) 

o Override  to  standard  specifications  (up  to  10  overrides) 

Input /Output  Options 
o LIS  Table  File  (Input) 

o GERBER  2032  Plotter  (Output) 

o Xynetics  Plotter  (Output) 

o MMS-32/Raster  Plotter  Interface  (Output) 

Point  Symbology 
o Circle 

o Dot 

o Arrow 

o Cross 

o Half-Arrow 

o Square 

o T riangle 

o Pyramid 

o Arc/Chord  (Mine  Symbol) 
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Various  combinations  of  point  and  lineal  symbology  can  be  generated. 


o Dash/Case 

o Dash/Cross 

o Dash /Dot 

o Dash/Tick 

o Dash/Circle 

o Line/ Arrow 

o Line  Center/Case 
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INTRODUCTION 


A.  Purpose 

The  purpose  of  Volume  I of  the  Final  Technical  Report  is  to: 
present  an  overview  of  the  project,  including  system  conversion, 
expansion,  test  results,  and  potential  system  improvements;  and 
define  the  procedures  for  operating  the  Graphic  Line  Symbolization 
System  (GLSS)  installed  at  the  Defense  Mapping  Agency  Aerospace 
Center  (DMAAC). 

B.  Organization 

Section  II  of  this  volume  describes  the  system  conversion,  ex- 
pansion, and  testing.  Section  III  of  this  volume  presents  a description 
of  the  operating  concepts  and  procedures  and  control  card  formats. 
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A.  Background  and  Summary 

PRC  Information  Sciences  Company  previously  developed  an 
experimental  symbolization  system  at  Rome  Air  Development  Center 
(RADC)  under  Contract  F30602-74-C -0027.  The  experimental  system 
was  written  in  COBOL,  FORTRAN  Y,  and  GMAP,  and  operates  on  the 
HIS-635  at  RADC.  Basically,  the  system  was  directed  at  restructuring 
digital  cartographic  features  to  conform  to  standardized  lineal  symbol 
patterns  for  digital  plotting.  Design  and  development  goals  of  the 
experimental  system  included: 

o system  should  be  flexible  enough  to  support  a wide  range  of 
product  requirements  and  expandable  to  support  new 
requirements; 

o job  execution  should  require  approximately  32K  words  of 
memory  (maximum  60K  words  of  memory); 

o user  control  for  variability  of  symbol  application  in  support 
of  a variety  of  production  processes,  e.  g. , compilation, 
proofing,  and  final  plotting; 

o improvements  in  processing  efficiencies  over  previous 
symbolization  algorithms; 

o improvements  in  product  quality,  carefully  balancing  efficiency 
and  quality;  and 

o compatibility  with  DMAAC  UNIVAC  1108  programming  stan- 
dards (reference  Operating  Instruction  171-23,  12  February 
1972). 


The  experimental  system  provided  for  input  and  output  of  a standard 
RADC  M MS-32  file  for  interfacing  with  digitizer  and  plotter  systems 
at  RADC.  The  symbolization  repertoire  included  all  major  lineal 
symbols  plus  the  set  of  point  symbols  which  are  normally  associated 
with  lineal  patterns. 

PRC/ISC  under  this  contract  was  tasked  with  conversion  and  expansion 
of  the  experimental  software  to  operate  at  DMAAC.  A summary  of  work 
performed  during  the  course  of  the  project  included  the  following: 

o GLSS  computer  programs,  originally  written  GE  COBOL 

and  FORTRAN  V,  were  compiled,  debugged,  and  tested  on 
DMAAC's  UNIVAC  1108  (System  A), 
o A new  software  routine  was  designed  and  implemented  for 

producing  plot  tapes  for  the  GERBER  2032  Plotter  (photo  head 
Model  OEH-B). 

o Symbol  specification  library  files  were  defined  and  built  for 
ATC  200  and  JOG  Series  Charts, 
o New  software  routines  were  designed  and  implemented  for 
generating  additional  point  symbols  (i.  e.  square,  triangle, 
pyramid,  and  arc/chord)  in  compliance  with  ATC  and  JOG 
product  specifications. 

o New  software  routines  were  designed  and  implemented  for 

formatting  output  files  to  interface  with  the  Xynetics  Plotter 
System  and  MMS-32/RAPS  software, 
o LIS  input  processing  routines  were  upgraded  to  operate  at 
DMAAC,  with  provisions  for  processing  feature  headers 
through  the  class,  type,  sub-type,  and  descriptor  levels, 
o Analysis  and  preliminary  design  work  was  performed  for 
developing  an  expanded  double -line  symbol  capability, 
o A feature  suppression  capability  was  added  to  GLSS  to 

symbolize  and  output  only  those  feature  groups  which  match 
feature  groups  included  in  the  specifications  files. 


II-2 


^ 


o A feature  code  masking  capability  was  added  to  provide 

additional  flexibility  in  defining  feature  groups  to  be  symbolized, 
o A stand  alone  software  program  was  installed  for  reading  a LB 
file  and  generating  a summary  of  features  residing  on  the  file, 
o Software  modifications  were  installed  which  resulted  in  major 
symbol  improvements  for:  (1)  producing  continuous  symbol 
pattern  through  data  point  buffers;  and  (2)  adding  new  tick 
symbol  capabilities  for  "double  half-tick"  and  "dash/multiple 
half -tick"  symbols. 

o Software  programs  were  delivered  to  DMAAC  along  with  interim 
operating  procedures. 

o Over  3 -months  of  resident  maintenance  services  were  provided 
to  DMAAC  which  consisted  of  system  testing,  user  training, 
and  detection  and  correction  of  software  problems. 

B.  System  Conversion  and  Expansion 

1 . System  Conversion 

Conversion  of  programs  from  the  HB-635  to  the  UNIVAC  1108 
basically  consisted  of:  performing  required  code  changes  to  source  files 
on  the  HIS -635  to  allow  for  differences  in  the  Honeywell  and  UNIVAC 
compilers;  creating  card  decks  of  source  files  required  at  DMAAC;  loading 
each  program  as  symbolic  elements  under  disk  file  DBM*UCPR-LT  using 
the  data  base  manager  system  on  the  UNIVAC  1108;  compiling  and  de-bugging 
each  source  program  and  preparing  relocatable  elements;  and  testing  the 
cycling  and  basic  capabilities  of  the  converted  software.  FORTRAN  and 
COBOL  versions  of  the  GLSS  common  data  buffer  were  built  using 
Blank  Common. 

Differences  in  HB  COBOL  and  UNIVAC  1108  ASCII  COBOL  and 
FORTRAN  Y and  FORTRAN  V which  required  program  code  changes  included 
the  following: 
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COBOL 

HIS  COBOL  UNIVAC  ASCII  COBOL 

:Ty  v • - < • 

o Word  Formats: 

. oiil  erlt  no  gr  * u ? ' >ji/  ' • - * ’ 

DISPLAY  6 Bit  BDC /Field  Data  DISPLAY -1 

PIC  9(8)  Comp-1  PIC  9(10)  Comp-4 

Comp-2  Single  precision  signed  Comp-1 

floating  point 

o Program  Calls: 

CALL  NAME  CALL  "NAME" 

o Reserved  Words: 

MESSAGE  MESSAGEU 

COUNT  COUNT Z 

o Working  storage  section  must  come  prior  to  common  storage  section 

in  ASCII  COBOL. 

o ASCII  COBOL  does  not  generate  a dummy  word  at  the  start  of 
common  (this  is  contrary  to  documentation). 
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FORTRAN 


Indexing  - Cannot  use  a variable  index  to  acquire  an  index 
i.  e.  - IXYZ  (1,  I CORDX  (ICURDX)) 

DO  Loops  - Cannot  use  the  variable  of  the  DO  for  any  set  value  after 
leaving  the  DO  loop  (FORTRAN) 
i.  e.  - DO  100  1=1,  N 

If  (I  . EQ.  INDX)  go  to  110 
100  continue 
110  continue 

INONO  = I 

Subroutine  as  a main  Routine  - cannot  have  a subroutine  as  the  main 

routine.  An  IGDM  error  (Guard  mode  or  undefined  sequence 

fault)  is  produced. 

i.  e.  - SUBROUTINE  MAIN 

DATA  STATEMENTS  - Cannot  have  the  following: 

DIMENSION  ITEXT(7) 

DATA  ITEXT  /37H  THIS  IS  NOT  ALLOWED  IN  UNIVAC  FORTRAN/ 
It  can  be  done  as: 

DIMENSION  IT EXT(6) 

DATA  ITEXT  (1)  /6HTHlSbI/ 

DATA  ITEXT  (2)  /6HSbALLO/ 

DATA  ITEXT  (3)  /6HWEDbBY/ 

DATA  ITEXT  (4)  /6HbUNIVA/ 

DATA  ITEXT  (5)  /6HCbFORT/ 

DATA  ITEXT  (6)  /feHRANbbb/ 

Subroutine  CALL  STATEMENT  - CALL  SUB  (1,  12,  65.4) 

SUBROUTINE  SUB  (II,  12,  Rl) 

11  = 4 

12  = 0 

Rl  = 6.  12 

Note:  the  above  may  cause  the  location  in  the  calling  routine 
(locations  containing  zero  twelve  and  six  five  point  4)  to  be 
changed  to  four,  zero  and  six  point  one  two. 
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Expansion  and  improvements  to  GLSS  were  primarily  designed 
and  installed  on  the  HIS-635  for  compiling,  unit  testing,  and  de-bugging. 
Installation  and  full  testing  of  new  capabilities  were  performed  on  the 
UNIVAC  1108  (System  A).  Most  of  the  software  integration  and  testing 
occurred  on  an  individual  change  basis  to  allow  for  modular  expansion  of 
the  system  and  interim  use  by  DMAAC. 


System  Testing 


The  purpose  of  this  section  is  to  describe  results  of  testing  the 
basic  capabilities  of  GLSS;  and  in  doing  so  illustrate  the  variety  of  symbols 
which  can  be  produced.  The  testing  also  reveals  process  timings  which  can 
be  used  for  run  time  projections.  DMAAC  conducted  similar  and  more  voluminous 
tests  which  contributed  to  verification  of  capabilities  and  detection  of  error 

conditions. 

1.  Test  Data 

A test  file  was  created  on  the  LIS  and  output  in  table  coordinate 
format.  The  test  graphic  was  digitized  at  20  micron  setting  (40  micron  steps) 
and  consisted  of  features  digitized  via  single  point,  trace,  and  point -point 
modes.  To  minimize  processing  time  for  testing,  the  file  consisted  of 
13  features  represented  by  17,855  data  points.  A line  center  plot  of  the 
test  file  is  shown  in  Figure  II- 1. 

2.  Test  Procedures 

Each  test  was  conducted  to  verify  the  basic  symbol  capabilities 
of  GLSS  and  to  identify  process  timings  for  major  types  of  symbol  applica- 
tions. A header  summary  (Figure  II- 2)  of  all  features  on  the  test  file  was 
first  run  to  verify  feature  header  codes.  The  purpose  of  each  test  was 
defined  followed  by  job  set-up.  Set-up  normally  included  creation  of 
specific  symbol  specification  cards  which  would  exercise  the  desired 
software  processes.  The  specification  override  option  was  normally 
employed  since  our  testing  was  directed  at  illustrating  the  symbol  repertoire. 
Following  job  execution  the  job  report  was  reviewed  for  accuracy  and  the 
plot  was  prepared  on  the  appropriate  plotter.  Plots  were  closely  examined 
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to  verify  that  proper  symbology  was  being  generated.  Process  timings  were 
computed  for  both  SUP  and  CPU  and  based  on  seconds/ 1000  data  points. 

3.  Run  Timings 

Execution  time  for  GLSS  runs  is  dependent  on  several  factors 
primarily  including  number  of  feature  data  points  processed  by  input, 
smoothing,  symbol  application,  and  output  processing  routines.  Variations 
in  processing  parameter  settings,  smooth  options,  symbol  types,  and  output 
formats  further  affect  the  execution  time. 

Based  on  sample  runs  conducted  against  the  test  file,  run  timings 
are  presented  in  Figure  II-3. 

4.  Symbol  Repertoire  Tests 

GLSS  generates  cartographic  symbols  based  on  specifications 
defined  by  the  user.  Symbol  specifications  can  be  supplied  to  the  system 
via  standard  files  created  for  specific  products  or  provided  in  the  job  card 
deck.  While  a wide  variety  of  symbol  patterns  and  sizes  can  be  produced 
a finite  set  of  legal  symbol  types  and  combinations  are  available.  Figures  II-4, 
U-5,  11-6,  and  II-7  demonstrates  the  basic  symbol  definitions  and  associated 
patterns  for  conventional  symbology  which  GLSS  can  support.  Other 
non -conventional  symbol  combinations  are  possible  although  should  be  tested  and 
verified  prior  to  production  use. 

D.  Potential  System  Improvements 

The  GLSS  system  at  DMAAC  currently  provides  a wide  range  of 
automated  symbology  capabilities  and  related  processes.  Processing  time 
for  GLSS  execution  is  very  reasonable  oorlsidering  data  volume  and  types 
of  processes.  Several  potential  areas  for  system  improvement  do  exist  and 
should  be  considered  by  the  Government.  Intersections  of  double -line 
symbols  is  a major  problem  and  is  discussed  separately. 

1.  Design  Concept  for  Improved  Double -Line  Symbology 

RADC  and  DMAAC  requested  PRC  to  examine  symbology 
problems  associated  with  double -line  symbols  currently  generated  by  GLSS. 

The  goal  of  the  analysis  was  to  scope  the  problem  and  define  a design  concept 
which  could  lead  to  development  of  new  or  modified  software  routines  for 


11-9 


u I 3 I QOuOoG  .(liij  0 t 

CON  C I N t • 9 V 9 

C u N bHACt  lUO 

eon  AnrlCN  .UjO 

CUN  h P * (.  t « 0 2 S 
CUN  AMficK  .UjO 


Ol 

• jOo 

• ‘JCO 

• J(j« 

• Oqu 

• 009 


o i o^oooooo  ,00-j  at  oi 

CUN  LInE  .9v9  .009 

CON  bPAct  .120  »QOO 

eon  ahtIca  » o j j .JOb 


o 1 03'joaoco  joou  jt  oi 

EUN  UAih  »23u  «00» 


CON  SPALt 
CUN  9PA(,t 
eon  AnTIcA 
eon  ipAct 
Eon  AmtIck 
Eon  SpAcE 

0 l 09'jOQUnO,. 
CUN  oaSh 

EON  SPAcfc 
CON  MTlcA 

Eun  iPACt 


• ubO 

* 300 

.090 

.000 

. 0 JO 

* 30b 

. 0 9 0 

.Ooo 

. 0 J 0 

*009 

.090 

• 300 

ooo 

10  lu 

.290 

.009 

• 3t>0 

. JOO 

• J J J 

. OOo 

• uhO 

■ ooo 

0 1 Jboujooo. Jto  Jt  ct 
>ow  l 1 nE  • Vy v • OOo 
.UN  bPAcE  *120  *aou 
.ON  rlcA  .CoU  • 0 (J  9 

O1060UJOUO  .OO'J  jt  01 
Eon  lInE  .999  .Jus 
cun  iP  A c t ' I/j  *000 
Eon  antIca  .uju  *jO» 
Eon  jp*cE  • u a u »0ub 
EuN  AtiTlCK  »Ojw  *309 

0107000030  000  ol  01 
CUN  0 Asm  ,290  .009 

CON  bpAct  • Ciso  .JOO 
Eun  opacl  .wo  *300 
cun  amtIca  .uju  »coo 


Olabuoooquoouo  ol  oi 

C°N  L l ’’E  .999  . JO 9 
CUN  SP  Act  *120  • JOO 

Cun  mt 1 ca  .OjO  • oc  9 


oi jvooaojovooo  jt  oi 

CON  ClNt  .999  .009 

CoN  bPAct  .2bO  *000 

Cun  T l c A . U 6 0 >006 

CON  bP*CE  .090  .Octt 

Con  T l c a .060  . J06 


Figure  II-  5 Tick  Specifications  and  Symbols  (Gerber  Plot) 
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Figure  11-7  Point  Specifications  and  Symbols 
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producing  an  improved  end  product. 


a.  The  Problem 

GL.SS  currently  produces  double -line  symbology  directly 
from  line -center  data  residing  in  a common  buffer  area;  and  generates 
case  symbols  independent  of  other  feature  lines  or  symbols.  Current 
symbology  directly  related  to  casing  includes: 

SYMBOLS  FEATURE 

Case  Major  Road 

Line/Case  Dual  Lane  Road 

Dash/Case  Road  U/C 

Arrow/Case/Arrow  Bridge  with 

Major  Road 

Since  the  generated  case  symbols  are  completely 
independent  of  other  features  and  symbols  being  generated,  several 
undesirable  situations  can  result.  Illustrated  below  are  examples  of 
conditions  which  can  result  from  current  double -line  symbology. 


CROSSING  OF  A CASEO 
ROAD  WITH  A SINGLE- 
LINE  SECONDARY  ROAD 


T- JOIN  OF  A SINGLE- 
LINE  SECONOARY  ROAD 
WITH  A CASED  ROAD 


T JOIN  OF  TWO  CASED 
ROADS 


T-JOIN  OF  A CASED 
ROAD  WITH  A SINGLE- 
LINE  SECONDARY  ROAD 
(OR  ANY  OTHER  FEATURE 
REPRESENTING  A TER- 
MINUS OF  THE  CASED 
HOAD 


General  Approaches 


Three  general  approaches  have  been  considered  for 
resolution  of  the  double -line  symbology  problem. 

o Software  Processing  - software  routines  to  detect  conflicts 
at  intersections  and  clip  or  join  the  appropriate  symbols. 

o Interactive  Symbol  Editing  - provide  edit  software  which  would 
rely  on  the  user  to  locate  feature  symbols  to  be  edited  and 
identify  the  type  of  software  edit  to  be  automatically  performed. 

o Photographic  Masking  and  Manual  Touch-Up  - masking  of  in- 
terior portions  of  cased  lines  and  manual  touch-up  of  finished 
plots. 

While  the  latter  two  approaches  have  merit  and  may  eventually  be  used  to 
some  extent,  the  direction  of  this  analysis  was  to  investigate  "software 
processes  " which  could  be  applied  to  the  problem. 

c.  Problem  Analysis 

Three  information  items  must  be  determined  such  that 
software  processes  can  accurately  clean-up  case  intersection  problems. 
These  items  are:  (1)  detection  and  holding  of  symbols  which  art  candidates 
for  edit  actions;  (2)  determining  which  candidate  symbols  conflict  with 
other  candidate  symbols;  and  (3)  determining  what  type  of  edit  (i.  e. , segment 
join  or  clip)  is  required  and  at  what  locations.  The  types  of  edits  are 
affected  by  size  of  double-line  symbols  generated  and  orientation  of  two  lines 
forming  a junction.  Two  major  approaches  were  examined:  (1)  perform 
intersection  editing  simultaneous  with  double -line  symbolization  of  each 
feature  or;  (2)  completely  symbolize  the  file  prior  to  intersection  editing. 

A major  question  is  --  is  intersection  editing  predictive  enough  to  perform 
prior  to  building  all  symbology? 

Double -line  symbology  creates  twice  as  many  feature 
symbols  and  approximately  twice  as  many  data  points  which  would  require 
storage  and  manipulation.  The  process  is  predictive,  although  the  time 
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which  would  be  consumed  to  accurately  derive  the  prediction  would  probably 
overwhelm  any  gains  due  to  data  compactness.  Thus  the  approach  decided 
upon  was  to  build  all  double -line  symbols  as  currently  performed  ani  store 
all  generated  symbols  which  are  candidates  for  intersection  edit  processing. 
This  approach  would  yield  the  cleanest  end  product  and  have  least  impact, 
and  associated  implementation  complexities,  on  the  current  GLSS  processing 
cycle. 

d.  Software  Organization  Considerations 

The  subroutine  "CASER"  currently  controls  (see  Figure  II- 9) 
all  double -line  symbol  generation.  CASER  generates  two  new  symbols, 
left  case  and  right  case,  until  the  current  feature  segment  (i.  e. , data  points) 
is  exhausted.  CASER  then  returns  control  to  SIMBOL  and  MONITR  for 
output  processing  of  each  of  the  new  symbol  segments  by  the  appropriate 
output  subroutine. 

Concerning  the  above  software  organization,  consideration 
was  given  to  possible  approaches  to  interrupting  the  process  sequence  for 
inclusion  of  "case  intersection"  software. 

Facts  to  consider  are: 

o Symbol  segments  produced  by  CASER  are  deposited  into  the 
common  feature  buffer  for  subsequent  processing. 

o CASER  returns  control  to  SIMBOL/MONITR/OUTPUT  for 
output  processing. 

o Assuming  all  symbolization  is  completed  just  prior  to  output 
processing,  very  few  current  GLSS  routines  would  be 
required  for  "intersection  processing"  and  output  processing. 

e.  Recommended  Design  Approach 

The  recommended  design  approach  for  the  double -line 
problem  is  to  store  double -line  symbols  and  associated  "conflict"  features 
on  random  storage  for  post-processing.  This  approach  provides  the  best 
potential  for  generating  clean  intersections  and  is  the  least  complex  to 
implement  within  GLSS.  This  capability  could  be  applied  to  any  type  of 
features  requiring  clean-up  editing  at  intersections. 

Basically  the  user  would  define  a threshold  value  for  edit 
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Figure  U-9  General  Flow  of  Case  Processing 
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acceptance  and  candidate  feature  types  for  intersection  processing! 
normally  including  features  which  require  double  line  symbology. 

GLSS  processing  would  cycle  in  a conventional  manner  except  at  the  output 
processing  step.  Prior  to  outputting  a feature  or  symbol  segment  the  feature 
type  would  be  checked  against  the  candidate  feature  list.  If  the  feature 
was  required  for  intersection  post -processing  the  normal  output  processing 
would  be  bypassed.  New  software  would:  (1)  build  a sequentially 
structured  file  containing  summary  information  about  the  feature,  such  as, 
header,  first/last  points,  bounding  rectangle,  data  list  random  access 
pointer,  etc. ; and  (2)  a random  accessabl  file  containing  the  bulky  data 
points  for  each  of  the  candidate  feature  symbols.  Consideration  should  be 
given  to  various  techniques  of  structuring  the  feature  data  lists  into  a 
gridded  file  or  maintaining  indexes  concerning  which  features  pass  through 
grid  areas.  The  purpose  of  this  type  of  file  organization  would  allow 

for  quick  association  of  feature  symbols  which  are  within  close  proximity. 
Otherwise  significant  processing  time  would  be  required  for  coordinate 
comparisons  of  each  feature  symbol. 

Completion  of  the  normal  symbolization  processing  would 
result  in  a tape  file  of  symbolized  features  plus  a disk  file  containing 
sequential  and  random  sub-files  of  candidate  feature  symbols  requiring  inter- 
section processing.  The  next  step  would  be  to  overlay  all  symbolization 
application  routines,  and  other  routines  not  required  for  intersection  edit 
processing.  The  overlaying  software  would  be  tasked  with  performing  the 
intersection  edit  processes  against  the  disk  resident  file.  Following 
intersection  editing  control  would  be  returned  to  MONITR  and  output  pro- 
cessing would  continue  as  normal. 

2.  System  Improvement  Considerations 

The  following  is  a list  of  potential  system  improvements  and 
expansions  for  consideration  by  the  Government. 

o Alphanumeric  Annotations  - the  capability  to  generate 

annotations  for  proof  plotting  and  feature  identification.  Plotter 
alphanumeric  subroutines  are  available  and  could  be  exploited 
by  GLSS. 
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Registration  Points  - GLSS  processes  and  outputs  only  file 
information  identified  as  features.  Current  users  of  GLSS  can 
define  registration  points  as  features  and  thus  such  points 
will  be  plotted  for  registration.  Consideration  could  be 
given  to  GLSS  using  control  points  on  the  LIS  files  for  generating 
registration  points. 

Color  Separation  Code  Usage  - GLSS  generates  a separation 
code  on  each  symbol,  based  on  the  symbol  specifications.  This 
code  could  be  used  by  plotter  systems  to  select  symbols  for 
plotting  on  separation  sheets  or  assigning  different  pen  colors. 
Optimization  of  Memory  Usage  - GLSS  currently  requires 
approximately  37K  to  4lK  words  of  memory  (depends  on  the 
output  module)  for  execution.  Minor  program  overlaying 
strategies  could  reduce  memory  usage  to  24K  to  32K  words. 
Additional  Point  Symbols  - other  geometric  point  symbols 
could  be  added  to  GLSS  to  provide  a wider  repertoire.  Symbols 
to  be  considered  includes:  cave,  building  (rectangle), 

powerline  pylons,  rock  and  astronomic  positions  (plus  symbol), 
etc. 

General  System  Usage  - GLSS  provides  a generalized  vehicle 
for  input,  data  buffering,  and  output  of  feature  files.  New 
application  routines,  such  as,  line  generalization,  can  be 
augmented  for  optional  use  during  symbolization  or  standalone 
use  for  special  applications. 
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SECTION  III 

OPERATING  PROCEDURES 


A.  Operational  Overview 

GLSS  is  a batch  system  which  operates  on  the  UNIVAC-1108.  Users 
of  the  system  are  responsible  for  defining  input  and  output  files,  symboli- 
zation specifications  and  parameters  to  be  applied,  and  special  processing 
options;  also  the  user  is  responsible  for  submittal  of  the  job  stream  and 
necessary  files,  and  review  of  outputs.  The  key  to  successful  use  of  GLSS 
is  understanding  of  the  concepts  and  major  elements  of  the  system.  Pre- 
sented below  is  a discussion  of  the  major  elements  of  GLSS  including: 


o Processing  Capabilities 

o Operational  Flow 

o System  Resources 

o Control  Cards 

o Symbol  Specification  Assignment 

o Job  Reporting 


I . Processing  Capabilities 


The  following  processing  and  symbolization  capabilities  are 
provided  by  GLSS. 


o Dashing  - variable  sizes  of  dashes  and  spaces 
o Casing  - variable  size  casing 

o Ticking  - full  tick,  half-tick,  alternating  half-tick,  double  tick 
o Point  Symbols: 

- Circle 
Dot 
Arrow 
Half-Arrow 
Cross 
Square 
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T riangle 
Pyramid 
Arc/Chord 


o 


o 


o 


o 


o 


o 

o 


Multiple  Symbol  Combinations  (e.  g.  , mixing  of  lineal  and  point 
symbols ) 

Assignment  of  specified  line  weight  and  color  separation  codes 
to  generated  symbols 

File  Input  and  Output  Processing: 

LIS  Table  File  (Input) 

Xynetics  (Output) 

GERBER  2032  (Output) 

RAPS/MMS-32  (Output) 

Line  Cleaning/Smoothing: 

Resolution  Maintenance 
Line  "back-up"  edit 
Angle  Bisecting 

Data  Culling  (based  on  slope  change  factor) 

Symbol  Specification  Control 

Building  and  updating  of  multiple  symbol  specification 
files 

- Override  to  standard  symbol  specifications  (at  job  run 
time) 

Job  process  and  diagnostic  reporting 

File  Summary  Capability  - provides  printout  of  feature  headers 
for  verification  of  classification  codes 


2.  Operational  Flow 

Presented  in  Figure  III- 1 is  a flow  diagram  of  operations  per- 
formed for  symbolization  processing. 


3.  System  Resources 

The  hardware  resources  required  for  operation  of  GLSS  in- 
cludes the  following: 

o UNIVAC-1 108 

o Permanent  Disc  Space 


Figure  IU“1 ' GL.SS  Operational  Flow 


MMS-32 
1 File 


o 


m 


7-Track  or  9-Track  Magnetic  Tape  Drives  (2) 

o 38K  to  41K  Words  of  Memory  (depending  on  output  format  re- 
quired) 

o Card  Reader 

o High  Speed  Line  Printer 

4.  Control  Cards 

Control  information  submitted  by  the  user  consists  of  operating 
system  control  data  and  GLSS  job  directives.  System  control  information 
is  preceded  by  a @ in  column  1.  The  only  system  cards  normally  modified 
by  the  user  are  the  two  @ASG  and  two  @USE  Cards  which  define  which 
standard  symbol  specifications  are  to  be  applied  to  the  particular  job  run, 
and  the  two  (®ASG  Cards  which  define  the  LIS  input  file  and  the  symbolized 
output  file. 

GLSS  control  card  formats  are  defined  in  Appendix  I.  The 
different  control  card  types  and  their  purpose  are  defined  below. 

INPUT  FORMAT  - defines  the  format  of  the  input  file. 

OUTPUT  FORMAT  - defines  the  format  of  the  output  file. 

SPECIAL  DIRECTIVES  OUTPUT  - special  option  for  generating  a 
line  center  file  containing  symbol  directives  in  the  header  records 
(not  currently  used  at  DMAAC). 

SMOOTH  OPTIONS  - specifies  the  type  of  smoothing  to  be  applied  to 
the  incoming  features. 

MINIMUM  DISTANCE  - defines  the  minimum  distance  between  points 
or  step  size  in  inches  to  be  accepted  by  SMOOTH  optional  processes. 

MAXIMUM  DISTANCE  - defines  the  point  spacing  in  inches  which 
should  be  interpreted  as  trace  vs.  point-point  types  of  data. 

SLOPE  DISTANCE  VALUE  - defines  the  distance  in  inches  to  be  used 
for  computing  symbol  orientations  for  lineal  features  or  for  SMOOTH 
C|>tion  6 (Data  Culling)  the  value  defines  the  "inclination  deviation 
factor"  in  degrees. 

SPECIAL  DIRECTIVES  INPUT  - indicates  that  symbol  specifications 
are  to  be  taken  from  the  incoming  header  records  instead  of  a stand- 
ard specification  file.  (Not  currently  used  at  DMAAC. ) 
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SPECIFICATIONS  OVERRIDE  - indicates  the  existence  of  symbol 
specifications  which  are  included  within  the  run  deck  and  will  be  ap- 
plied to  matching  features  instead  of  standard  specifications. 

SYMBOL  FEATURE  CARD  - defines  the  feature  classification,  de- 
scriptors, and  color  separation  codes  for  the  group  of  features  to  be 
symbolized  with  the  override  specifications. 

SYMBOL  SPECIFICATION  CARD  - specifies  the  attributes  of  a sym- 
bol piece. 

END  SYMBOL  CARD  - indicates  the  end  of  a specification  override. 
END  CARD  - indicates  the  end  of  GLSS  control  cards. 


5.  Symbol  Specification  Assignment 

The  system  provides  flexible  and  responsive  techniques  for  de- 
fining symbology  to  be  applied  to  feature  groups.  Since  conventional  pro- 
ducts are  symbolized  based  on  standard  specifications  the  system  allows 
the  user  to  build  master  specification  files  for  each  product.  Product 
specification  files  are  permanently  stored  and  readily  accessible  at  job  run 
time.  To  allow  the  user  to  override  standard  symbol  specifications  for 
specific  jobs  the  GLSS  job  stream  allows  the  user  to  define  feature  sym- 
bology (maximum  of  10  symbol  overrides)  which  is  to  be  applied  to  only 
that  specific  nin.  During  job  execution  the  override  specifications  are 
examined  for  feature  matching  prior  to  accessing  a standard  specification 
file. 

Feature  symbolization  is  defined  in  terms  of  symbol  pieces. 

A feature  can  be  symbolized  by  one  or  up  to  eight  symbol  pieces.  Each 
symbol  piece  is  described  as  to  conformity  to  line  orientation,  symbol  type, 
symbol  size,  and  line  weight  (see  Appendix  1-12  for  card  formats).  Figures 
II-4  through  U-7  presents  sample  symbol  specifications  and  resultant  symbol 
patterns.  Symbol  pieces  currently  provided  include  the  following: 


LINEAL  SYMBOLS 

LINE 

DASH 

SPACE 

CASE 


POINT  SYMBOLS 

DOT 

CIRCLE 

TICK 

HALF  TICK 

ALTERNATING  HALF  TICK 
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POINT  SYMBOLS  (Continued) 

ARROW 

HALF  ARROW 

CROSS 

SQUARE 

TRIANGLE 

PYRAMID 

ARC/CHORD 
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B.  Symbolization  Operating  Procedures 


1 . Job  Planning 

The  key  to  successfully  applying  GLSS  is  comprehensive  plan- 
ning for  the  symbolization  run.  The  user  should  be  knowledgeable  of  the 
input  file  to  be  symbolized,  the  product  being  supported  and  therefore  the 
symbology  required,  GLSS  capabilities  and  constraints,  and  output  format 
required.  Each  unique  feature  group  contained  on  the  input  file  which 
matches  a feature  group  contained  on  the  symbol  specification  file  or  over- 
ride file  will  be  symbolized  and  output,  otherwise  that  feature  group  will 
default  and  be  suppressed.  If  the  user  does  not  know  exact  header  codes  on 
the  feature  file,  the  input  file  can  be  processed  by  GLSSHEADSUM  which 
will  print  out  all  headers  on  the  file  (see  Appendix  III).  Any  non-standard 
symbology  required  should  be  identified  and  verified  for  acceptability  by 
GLSS.  The  quality  of  original  line  center  plots  and  data  point  resolution 
should  be  examined  to  determine  if  some  level  of  line  cleaning  or  data  re- 
duction is  desired. 

The  following  smooth  options  are  available: 

0 - no  cleaning  is  performed  (original  line  center  is  passed  to  sym- 
bolization processes). 

1 - deletes  those  data  points  (except  special  points)  which  are  less 
than  specified  distance  (MINIMUM  DISTANCE)  from  adjacent  points. 

2 - Computes  and  passes  the  mid-points  of  all  line  segments  (except 
those  defined  by  special  points)*  and  then  performs  option  1. 

3 - performs  option  1 and  then  checks  and  corrects  for  line  back-up 
conditions  for  adjacent  line  segments. 

4 - performs  options  2 and  3. 

5 - performs  option  2 twice. 

6 - performs  option  1 and  then  data  culling  based  on  minimum  angle 
specified  by  the  slope  parameter. 

^Special  points  include  end  points,  adjacent  points  which  exceed  maximum 
distance  specified,  and  points  which  are  flagged  as  special  (e.g„,  inter- 
sections). 
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J ob  Set-Up 


The  user  should  obtain  a copy  of  a standard  GLSS  job  stream 
and  modify  the  appropriate  cards.  The  normal  modifications  are  associated 
with  I/O  files  and  formats,  specification  files,  SMOOTH  options,  and 
specification  overrides.  A sample  job  stream  is  presented  below. 


@RUN  (Estimate  5fc  SUP  Time  should  be  2 to  5. 

Sec./ 1000  data  points) 

@HDG  ****UNCLASSIFIED**** 

@ASG,  A DBM*UCPR-LT. 

@ASG,  A DBM*UCPR -ATCS.,  F/l/TRK/1/  (Spec,  sequential 

@US E 8,  D BM * U CPR - ATCS.  disk  file>- 

«JJASG,  A D BM*U  CPR  - A T CR.  ,F/l/TRK/5/  (Spec,  random  file). 

@USE  2,  DBM *U CPR -ATCR. 

@ASG,  T 3,  U9H,  NNNNNN  (Input  Tape  Number) 

@ASG,  T 9,  U9H,  NNNNNN  (Output  Tape  Number) 

@XQT  DBM*UCPR-LT.  GLSSXYN(GLSSGERBER  or 

GLSSMMS) 

1 INPUT  LIS 

2 OUTPUT  XYNET  (or  GERBER,  GERBPT,  or  MMS) 

3 MMSDIR  NO 

4 SMOOTH  N(0  j<  N r<6) 

5 MINIMUM  . nnn  (normally  . 001  <nnn  :S  . 0 ! 0 in  inches ) 

6 MAXIMUM  . nnn  (normally  .010  <n  100  in  inches! 

7 SLOPE  . nnn  (normally  « .040  to  .080  in  inches  or  for 

SMOOTH  6 000  £ nnn  <090  in  degrees) 

8 DIRECT  NO 

9 SPEC  NO  (or  YES) 


If  card  9 contains  a YES  additional  GLSS  control  cards  are  required  (see 
Appendix  I for  specific  card  formats). 

END 

@FEN 

Note:  Underlined  items  above  are  optional  job  parameters. 
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Execution 


Execution  of  a GLSS  run,  once  properly  set  up  merely  requires 
submittal  of  the  tapes  for  input  and  output  (if  tapes  are  not  already  contained 
in  computer  center's  tape  library)  and  submitting  the  job  control  deck. 

4,  Job  Run  Validation 


Each  job  execution  will  produce  a system  job  report  and  GLSS 
processing  summary  report.  The  system  job  report  should  be  verified  for 
normal  termination.  The  user  may  also  wish  to  note  the  CPU  & SUP  time 
for  the  execution.  GLSS  generates  six  reports  which  should  be  verified  by 
the  user. 

Request  Report  - identifies  the  job  options  requested:  input  and  out- 
put formats,  smooth  option  and  associated  parameter  settings. 

Specifications  Override  Report  - if  overrides  were  defined  by  the 
user  they  will  be  listed  for  verification. 

Input  Report  - provides  a summary  of  feature  information  read  from 
the  input  file:  number  of  files,  number  of  feature  headers,  number 
of  data  point  records,  and  number  of  data  points. 

Symbolization  Report  - identifies  the  types  of  lineal  symbolization 
performed  and  associated  numbers  of  features  processed,  symbol 
segments  and  data  points  generated.  If  smoothing  was  requested 
the  number  of  data  points  processed,  deleted,  and  passed  is  pre- 
sented. 

Output  Report  - provides  a summary  of  feature  information  written 
on  the  output  file:  number  of  files,  number  of  feature  headers,  num- 
ber of  data  records,  and  number  of  data  points.  The  number  of  fea- 
ture headers  and  number  of  data  records  should  be  the  same  for  both 
GERBER  and  Xynetics  files. 

Error  Report  - any  error  situations  encountered  by  GLSS  software 
processes  are  reported. 
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C.  Specification  File  Building  and  Maintenance  Procedures 

1.  Symbol  Specification  File  Definition 

The  symbol  specification  directive  generation  is  a major  capa- 
bility of  the  Graphic  Line  Symbolization  System.  The  master  specification 
file  concept  allows  the  user  to  define  and  build  a set  of  symbol  specifications 
for  feature  groups  and  selectively  reuse  the  file  for  subsequent  runs.  The 
user  must  define:  the  file  name,  usually  associated  with  a product  (e.  g. , 
ATCS);  all  feature  groups  to  be  symbolized,  and  symbol  specifications  for 
the  feature  group.  Any  feature  group  not  defined  will  be  omitted  from 
further  processing.  Product  specifications  normally  contain  symbolization 
patterns  and  drafting  specifications  to  be  applied  to  feature  groups.  The 
drafting  specifications  must  be  examined  to  determine  if  the  patterns  can 
be  replicated  by  GLSS  and  the  sequence  of  symbol  pieces  required.  Every 
pattern  must  be  uniquely  defined  in  terms  of  conformity,  symbol  type,  size, 
and  line  weight.  For  example  the  JOG  specifications  for  drafting  a Single 
Track  Railroad  (Feature  701)  is  the  following: 

.150 

* - r*~  ~"“j  .016 

.oog' 


GLSS  specifications  to  generate  the  above  symbols  are  defined  as  follows: 


Conformity 

Symbol  Piece 

Symbol  Size 

Line  Weight 

CON 

LINE 

.999 

.016 

CON 

SPACE 

. 150 

.000 

CON 

TICK 

.060 

.008 

All  symbol  pieces  required  are  conformal  (CON)  with  the  orientation  of 

the  feature  line.  The  first  symbol  piece  LINE  tells  the  system  to  first  generate 

the  full  line  center  (.999  implies  infinity)  on  the  output  file  and  assign 
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a line  weight  of  . 016.  The  second  symbol  piece  (SPACE)  is  then  applied 
to  the  start  of  the  feature  for  a distance  of  . 150.  A conformal  tick  of  . 060 
is  then  generated  at  the  current  location  and  assigned  a line  weight  of  . 008. 
The  last  two  symbol  pieces  are  iteratively  applied  to  the  end  of  feature  line 
center.  Examples  of  symbol  specifications  and  resulting  symbol  patterns 
generated  by  GLSS  are  presented  in  Figures  11-4  through  11-7. 

2.  Set-Up  it  Execution 

The  symbol  specification  files  are  built  and  updated 
program  (symbol  name  SPEC)  that  operates  independently  of  GLSS.  Two 
permanent  data  files  are  required  for  the  execution  of  the  SPEC.  The  first 
file  (file  code  08)  is  a permanent  sequential  data  file  which  contains  the 
feature  descriptor  codes  and  pointers  to  the  associated  specifications  on 
the  random  file.  The  second  file  (file  code  02)  is  a permanent  random 
data  file  (35-word  records)  which  consists  of  symbol  piece  directive 
specification  data. 

Symbol  control  data  includes  specifications  for  all  symbol 
patterns  to  be  applied  to  lineal  features.  Control  data  is  input  to  the  master 
symbolization  specification  files  via  data  cards.  The  symbol  specifications 
are  organized  by  product  and  feature  within  product.  A feature  is  defined 
in  terms  of:  feature  class,  type,  subtype,  codified  descriptors,  symbol 
conformal /non -conformal  information,  color  separation  sheet  numbers, 
symbol  piece  type(s),  symbol  piece  size(s),  and  symbol  line  weight(s)  for 
a specific  feature  group.  Specification  file  BUILD/UPDATE  control  cards 
are  presented  in  Appendix  III.  A sample  SPEC  run  stream  is  presented  in 
Appendix  IV. 

Execution  of  the  symbol  specification  file  build  or  update  runs 
are  accomplished  after  the  user  has ‘generated  the  proper  UNIVAC  1108 
control  cards  along  with  his  SPEC  control  directive  data  cards  and  symbol 
control  data  cards. 

Validation  of  the  job  run  is  accomplished  by  examining  the 
printer  output  report  generated  by  the  execution  of  the  SPEC  job  stream. 

The  printer  output  report  will  depict  the  mode  of  execution  (BUILD  or 
UPDATE).  It  will  also  depict  the  random  record  number  built  or  updated, 
the  feature  descriptor  definition  codes,  color  separation  sheet  numbers, 
conformal/non-conformal  information  and  the  symbol  piece  type(s),  size(s). 
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and  line  weights)  associated  with  each  feature  descriptor  defined.  Also 
printed  is  the  comment  extracted  from  the  symbol  feature  card. 
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CARD  1 - INPUT  FORMAT 


symbolization  will  be  input. 


CARD  2 - OUTPUT  FORMAT 
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This  control  card  is  required  and  must  be  the  second  card  in  the  user's  generated  input 


CARD  4 - SMOOTH  OPTIONS 


This  control  card  is  required  if  symbolization  is  to  be  applied  and  must  be  the  fourth  card  in 


CARD  6- MAXIMUM  DISTANCE 


This  control  card  is  required  if  symbolization  is  to  take  place  and  must  be  the  sixth  card  in 
the  user's  generated  input  cards. 


CARD  9 - SPECIFICATION  OVERRIDE 
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SYMBOL  PIECE  SPECIFICATION  CAUD 
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@RUN 
@HDG 
@ASG,  A 
@ASG,  T 
@XQT 
@FIN 


DBM*UCPR-LT. 

3,  U9H,  nnnnnn  (LIS  Table  File  Tape  Number) 
DBM*UCPR-LT.  GLSSHEADSUM 


Information  printed  out  includes  the  following: 


Feature 
Sequence  # 


Class,  Type, 
Subtype 


Descriptors 


040809 


61000000 


NUMBER  POINTS  = 
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APPENDIX  ni 

SPECIFICATION  FILE  BUILD/UPDATE  CONTROL  CARD  FORMATS 
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Mti'IlI'/YY  EUILE 


APP  III -2 


This  control  card  is  necessary  and  must  be  the  first  control  card.  The  first  input  control 
card  for  the  symbol  specification  setup  must  contain  the  date  and  mode  of  run. 


SYMBOL  FEATURE  CARD 
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This  control  card  is  needed  for  each  symbol  specification  and  must  precede  the  symbol  piece 
descriptor  card(s)  associated  with  each  override. 


SYMBOL  PIECE  SPECIFICATION  CARD 
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SPECIFICATION  FILE  BUILD  AND  UPDATE  JOB  STREAMS 


@RUN 

@HDG 

@ASG,  A DBM*UCPR-LT. 

@USG, A DBM*UCPR-ATCS.,F/1/TRK/1/  (File  Name) 
@USE  8,  DBM*UCPR-ATCS.  (File  Name) 

@ASG,A  DBM*UCPR-ACTR. , F/l/TRK/5/  (File  Name) 
@USE  2,  DBM*UCPR-ACTR  (File  Name) 

@XQT  DBM*UCPR-LT.  SPEC 


11/12/75  BUILD 


01 1000000000D0 

01  01 

C0MMENT  FIELD 

N0N  SQUARE 

.250 

.008 

N0N  CR0SS 

. 100 

.008 

N0N  ARC0RD 

. 100 

.008 

E0SYMB 

@FIN 


SAMPLE  JOB  STREAM  FOR  UPDATE  MODE 


@RUN 

@HDG 

@ASG,  A DBM*UCPR-LT. 

@ASG, A DBM*UCPR-ATCS.  .F/l/TRK/1/ 

@USE  8,  DBM*UCPR-ATCS.  (File 

@ASG,  A DBM*UCPR-ACTR.  . F/I/TRK/S/ 
@USE  Z,  DBM*UCFR-ACTR  (FUe 

@XQT  DBM*UCPR-LT.  SPEC 

11/12/75  UPDATE 


3 


05070000000000 

03 

04 

C0N 

LINE 

.999 

.000 

C0N 

SPACE 

.250 

.000 

C0N 

HTICK 

.060 

.008 

E0SYMB 

20 

31070000000000 

01 

01 

C0N 

LINE 

.999 

.008 

E0SYMB 


@FIN 


(File  Name) 

Name) 

(File  Name) 

Name) 
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MISSION 

of 

Rome  Air  Development  Center 


RADC  plans  and  conducts  research , exploratory  and  advanced 
development  programs  in  command,  control,  and  coasnonlcatlonr, 
(C3)  activities,  and  in  the  C*  areas  of  information  sciences 
and  intelligence.  The  principal  technical  mission  areas 
are  communications , electromagnetic  guidance  and  control, 
surveillance  of  ground  and  aerospace  Objects,  intelligence 
data  collection  and  handling,  information  system  technology, 
ionospheric  propagation,  solid  state  sciences,  micromave 
physics  and  electronic  reliability,  maintainability  and 
compatibility . 


